# Этапы реализации приложения

Более подробно этот процесс описан в статье [Приложение от проекта до релиза: этапы реализации](https://habr.com/ru/articles/752782/)

Ниже изложены основные тезисы.

Перед началом реализации приложения мы ожидаем от аналитики хотя бы sequence-диаграммы.

## Этап I. Проектирование бизнес-сущностей.

Проектирование любого приложения нужно начинать с создания предметной области - бизнес-сущностей и связей между ними.
Определите, про что будущий сервис.
Как правило, это одно слово. Например, приложение, управляет лотерейными билетами.
Значит, главная сущность - лотерейный билет.
В таком случае, мы создадим сущность `LotteryTicket`, опишем её первоначальные свойства.
Определим другие сущности, второстепенные по отношению к лотерейному билету (например, "тираж", "точка продажи"), опишем их.
Только когда мы будем иметь целостную картину мира в рамках предметной области продукта, мы перейдём ко второму этапу.

Бизнес-сущности меняются постоянно, поэтому нет смысла долго задерживаться на первом этапе.
Можно переходить ко второму этапу, как только картина мира становится ясна.

## Этап II. Проектирование сервисов бизнес-логики.

Вторым этапом является описание требуемой функциональности через интерфейсы. 

Интерфейсы - это важнейший элемент архитектуры.
Посмотрите на строящуюся высотку.
Казалось бы, можно построить сначала первый этаж и заселить его, потом построить второй, третий, и так далее.
Конечно, при превышении строительных норм примерно после n-ного этажа дом начнёт трещать, но мы-то начинаем строить с первого этажа, про остальные этажи мы начнём думать, когда они потребуются.

Но мы знаем, что так не работает.
Сначала мы проектируем здание целиком.
Потом строим каркас.
Потом строим стены и всё остальное.

Конечно, приложение - это живой организм, который будет постоянно меняться.
Тем важнее построить скелет приложения, основанный на стабильных компонентах, коими являются интерфейсы.
Имея скелет, основанный на стабильных компонентах, гибко соединённых между собой, нам будет намного проще поддерживать всю конструкцию.

Итак, на втором этапе мы проектируем логику бизнес-сущностей через реализацию интерфейсов.
Мы можем полностью спроектировать основные узлы приложения через интерфейсы, не написав ни одной строчки реализации. 
Имея интерфейсный скелет приложения, мы можем приступать к написанию тестов.

Данный этап проектирования включает в себя составление блок-схем.

## Этап III. Написание тестов и реализация бизнес-логики.

Имея готовые бизнес-сущности и бизнес-логику, основанную на интерфейсном скелете, мы можем приступить к написанию тестов. 
**Test Driven Development** - очень непривычный подход для многих разработчиков, и поэтому внутри каждой команды допускается самостоятельное определение, когда будут написаны тесты - до реализации основной функциональности или после. 
Предлагаем две стратегии на выбор:

1. Написание тестов ДО реализации функциональности. Сначала пишется тест, благо, после второго этапа разработки, для этого есть всё необходимое - потом реализуется функциональность так, чтобы тест проходил.
2. Написание тестов ВО ВРЕМЯ реализации функциональности. Сначала пишется функциональность, потом, сразу - тест. Функциональность, не покрытая тестами, не допускается в релиз.

Реализация бизнес-логики в части доступа к данным не может не включать в себя описание DAO. 
Но DAO не относится к бизнес-логике. 
Здесь возможны два варианта:

1. Реализация мок-сервисов DAO на время реализации третьего этапа. Такие сервисы проходят под специфическим профилем (например: mock-dao). Как результат, у нас уже будут готовые моки DAO, которые могут пригодиться для тестирования бизнес-логики сервиса "из коробки" в каком угодно окружении под моковым профилем.
2. Реализация сервисов DAO в целевом виде. Но нужно понимать, что это очень трудоёмкий процесс, включающий описание репозиторных сущностей, маперов и логики DAO.

Способ необходимо выбирать из специфики сервиса. 
Если тестирование затрагивает stateless операции, тогда предпочтителен первый способ. 
Если, к примеру, при тестировании необходимо использовать цепочку вызовов с реальным id, больше подойдёт второй подход.

## Этап  IV. Интеграция.

На этом этапе, происходит интеграция с внешними интерфейсами - репозиторием, клиентами.

Для каждого случая, будь то репозиторий или клиент, сначала описываются модели - репозиторные сущности для базы данных / модели API для клиентов. 
Далее, описывается мапинг с бизнес-моделями. 
В конце описываются интерфейсы и их реализация. 
В целом, этот подход повторяет этапы 1-3 для создания приложений, в масштабе DAO.